As the Internet becomes more and more pervasive, better technology is constantly being developed for displaying web contents. In this respect portal servers have become a technology of choice in delivering web contents to users. Typically, a portal server is a portal program (e.g. WebSphere Portal Server from International Business Corp. of Armonk, N.Y.) that organizes web contents into a portal page composed of portlets. A user, for instance, can set up his/her own portal page having portlets for news, weather and sports. The portal program would then obtain the desired web contents from appropriate content providers, aggregate the web contents and generate a portal page for end users.
A traditional web application allows a user to fill out a form on a web page, and when the form is submitted, the web browser sends a request to the web server. The web server processes any information sent through the form, and then responds to the web browser with a new web page. In this way, a lot of bandwidth may be wasted since much of the web contents in the first page may also be contained in the second page. Because a request has to be transmitted to the web server on every interaction with the application, the application's response time is dependent on the response time of the web server. This leads to a much slower user interface of a web application than that of a native application.
In the prior art, a portal system is just such a traditional web application. Whenever a user submits a form on a portlet, the portal server will respond by sending a new portal page. In fact, however, it is needless to send web contents of other portlets in the portal page. And it is enough to reload only the web contents of the portlet with which the user is interacting.
An emerging technology, called as AJAX (Asynchronous and JavaScript XML), for asynchronous web is developed for refreshing part of a page instead of refreshing the whole page on every interaction between the user and application. In an AJAX application, when a user submits a form in a page, instead of the web browser directly sending a HTTP (Hypertext Transfer Protocol) request to the web server, a script program, usually a JavaScript program, resident on the web browser receives the user's request and sends a XMLHTTP (Extended Markup Language HTTP) request to the web server in background through an API (Application Program Interface), so as to retrieve only the needed web contents instead of the whole page and perform corresponding processing to partly refresh the page when receiving a response from the web server. In this way, the application response is speeded up, because the amount of data exchanged between the web browser and the web server is greatly reduced. And the processing time of the web server is saved because much of the processing is performed at client side.
At present, portlet developers can use AJAX to develop portlets so as to provide an asynchronous portal program. But now the most popular portlet programming models are all based on non-AJAX technology (e.g. JSR168), and almost all existing portlets have been developed in this way. Therefore, the solution of using AJAX to develop portlets would have the following shortcomings:
a) Using the new AJAX requires writing portlets in a completely new way, and rewriting millions of existing portlets is almost impossible.
b) Portlet developers have only to focus on portlet logic, and using AJAX will increase the complexity of the development because the developers have to take care of a lot of programming details.
Another solution for providing an asynchronous portal page is to use the “IFrame” (Inner Frame) tag in HTML, which can display a whole HTML page anywhere in another HTML page. The page in an IFrame can be loaded and operated separately. Thus, by combining portlets and the IFrame, asynchronous updating of portlets may be realized. However, this solution has the following defects:
a) The size of an IFrame is unchangeable. If its size is not big enough for the web contents, a scroll bar will be shown. This means dynamical adjustment of the portal page's layout is impossible when the web content of a portlet is changed.
b) All the web pages in an IFrame are separated, so that any common resource (e.g. CSS, images and others) cannot be shared. The same resource must be downloaded repeatedly.
In view of the forgoing, there apparently exists a need for a system and method for providing asynchronous portal pages. Specifically, there exists a need for a system and method for providing asynchronous portal pages in a portal system where the portlets are developed using traditional web technology (i.e. developed by using programming models based on synchronous refreshing technology).